Multi-target the serialization libraries to netstandard2.1 and ship them to Unity - #68
Merged
Merged
Conversation
…hem to Unity NxGraph.Serialization and NxGraph.Serialization.Abstraction were net8.0-only on the recorded grounds that no netstandard2.1 consumer existed. One does now: the Unity graph editor loads and saves graph payloads in-editor, so both libraries join the core in targeting net8.0 + netstandard2.1, and a second UPM package ships them. The netstandard2.1 leg costs three small shims per assembly (init-only marker, caller argument attribute, argument-null guard), compiled in only on that TFM because the core's copies are internal. NxGraph.Serialization adds Compat.cs for the text-IO overloads the platform lacks — the conditional lives in the helper so ~30 call sites compile unchanged — plus an explicit System.Text.Json reference pinned to the 8.0.x line, so both TFMs serialize identically, and CopyLocalLockFileAssemblies so the dependency closure lands beside the assembly for staging. No public surface differs between the two TFMs. The public API test grows a netstandard2.1 baseline per shipped assembly, walked through a MetadataLoadContext over the netstandard2.1 build output; a baseline that stops matching its net8.0 twin means a member went TFM-conditional, which is a design change rather than a baseline update. com.enzx.nxgraph.serialization bundles its own third-party closure (MessagePack, System.Text.Json, BCL facades) rather than asking consumers to resolve it — duplicate assembly risk traded for zero setup. Its .meta sidecars are the reviewed allowlist of what staging may write, so adding a dependency breaks stage-binary until the new closure is reviewed. stage-source still refuses to stage it: source mode compiles the core as NxGraph.Unity.Runtime, which a prebuilt NxGraph.Serialization.dll cannot bind to. unity/NxGraphDev is the development harness that verifies this end to end — a batch-mode round-trip through the staged plugins. It references both packages by relative path, so Unity works against the tree directly, and its generated projects are ignored so they never collide with NxGraph.sln.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
NxGraph.SerializationandNxGraph.Serialization.Abstractionwere net8.0-only on the recorded grounds that no netstandard2.1 consumer existed. One does now — the Unity graph editor loads and saves graph payloads in-editor — so both libraries join the core in targetingnet8.0+netstandard2.1, and a second UPM package ships them to Unity.What's in it
Multi-targeting. Three small shims per assembly (init-only marker, caller-argument attribute, argument-null guard), compiled in only on the netstandard2.1 leg because the core's copies are internal.
NxGraph.SerializationaddsCompat.csfor the text-IO overloads the platform lacks — the conditional lives in the helper, so ~30 call sites compile unchanged on both TFMs — plus an explicitSystem.Text.Jsonreference pinned to the 8.0.x line so both TFMs serialize identically, andCopyLocalLockFileAssembliesso the dependency closure lands beside the assembly for staging.No public surface differs between the TFMs. The public API test grows a netstandard2.1 baseline per shipped assembly, walked through a
MetadataLoadContextover the netstandard2.1 build output. A baseline that stops matching its net8.0 twin means a member went TFM-conditional — a design change, not a baseline update.com.enzx.nxgraph.serializationbundles its own third-party closure (MessagePack, System.Text.Json, BCL facades) rather than asking consumers to resolve it: duplicate-assembly risk traded for zero setup. Its.metasidecars are the reviewed allowlist of what staging may write, so adding a dependency breaksstage-binaryuntil someone reviews the new closure.stage-sourcestill refuses to stage it — source mode compiles the core asNxGraph.Unity.Runtime, which a prebuiltNxGraph.Serialization.dllcannot bind to.unity/NxGraphDevis the development harness that verifies this end to end, via a batch-mode round-trip through the staged plugins. It references both packages by relative path so Unity works against the tree directly, and its generatedcsproj/sln/Libraryare ignored so they never collide withNxGraph.sln.Verification
dotnet run --project NxGraph.Build -- ci— green: 0 warnings, 0 errors, 83.4% line coverage against the 70 threshold.Note for the reviewer
unity/README.mddocuments the graph editor's usage, but the editor code itself is deliberately not in this PR — it lands on the branch that follows, so that the editor work starts cleanly from main. The README is one PR ahead of the code it describes.